OLED GC9A01 Applications with MCU 18F27K42


modele Bleu ROND GC9A01 1,28" SPI 240x240 7 pins 7 Pins : 7 Vcc 6 Gnd 5 SCL 4 SDA 3 DC 2 CS 1 RST pas de commande de l'éclairage, écran toujours allumé (LED) mais possibilité de commander la dalle sur OFF	modele Rouge sur platine rectangulaire 1,28" SPI 240x240 8 pins 8 Pins : 8 ..Vcc 7 ..Gnd 6 ..CS -------> CS/ RC1 5.. RES ------> RST/ RC0 4.. A0 ou D/C ---Data=1/Commande=0 ...RC2 3.. SDA ------> MOSI RC5 2.. SCK ------> SCK RC3 1.. LED -------> 1K----+Vcc avec porte carte SD au dos du module (5 pins TF card)

Test Ecran sur port B avec platine BASE 18F26K22, 100% ASM
rev 05/03/2023
Software ..100% en ASM
OLED Rond Bleu CG9A01 7 pins ET
OLED Rouge sCG9A01 8 pins, connectés en parallele
+ connection LED au +VCC....... via R= de 470ohms à 15K = éclairage maxi ..
L'éclairage diminue fortement avec R=100K
.... à suivre ..réglage luminosité via PWM1 sur pin LED.
*nota: si pin LED non connectée => Ecran NOIR

Cablage en parallèle des 2 OLED ... No problemo !

HARDWARE :

Connections:
#define LCD_SCK LATB,0 ; clock horloge SPI
#define LCD_MOSI LATB,1 ; SDA/Data /Mosi
#define LCD_DC LATB,2 ; DC/ choix Commande (0) ou Data(1)
#define LCD_CS LATB,3 ; Chip Select en début de sequence
#define LCD_RST LATB,4 ; RST ( reset actif sur 0, normal=1)
Alimentation +Vcc 3,5V Gnd=0V

SOFTWARE
rev 05/03/2023
voir fil sur Fantaspic.fr : Ecran OLED rond GC9A01
Test direct du programme (V.O de Francois77) , 100% 3en ASM
pour verifir si mes 2 ecrans sonts OK ...
GC9A01_Bleu_OK_PF_18F26K22_2023-0604.asm

compilé OK ...avec MPLAB

Chargé GC9A01PF_18F26K22.HEX avec Pickit3
..résultat OK .. no problemo sur les 2 ecrans !

images/t_Test_OLED_ronds_CG9A01_Bleu_Rouge_18F26K22_asm_2023-03.gif

Adaptation pour BASE 18F27K42
GC9A01PF_18F27K42_2023-0309.asm
GC9A01PF_18F27K42_2023.HEX
* presque OK !

car Bug uniquement sur la partie écriture message !
je n'ai pas investigué pourquoi
.. carte la suite en Langage C !

Test OLED GC9A01 ( MikroC 7.60) BASE 18F2K42, SPI bit Bang

Compilation conditionnelle pour pouvoir utiliser :
soit le SPI Bit- Bang, connections sur le PORT B,soit connection SPI Hardware , sur le PORT C :

#define SPI_Bit_Bang
#ifdef SPI_Bit_Bang
#define _RST LATB0_bit // Reset TFT
#define _CS LATB1_bit // CS
#define _DS LATB2_bit //Command (_DS=0) Parameter (_DS=1)
#define _CLOCK LATB3_bit;
#define _MOSI LATB5_bit;
#endif
choix fait en validant ou pas la ligne #define SPI_Bit_Bang

Rappel sur le protocol SPI Oled
Test avec SQA Anlyser 50Mhz :
* partie Init OLED

images/t_SQA_Init_OLED_OK_avec_SPI_bit_bang_MC_20230317.gif

SOFTWARE : ( SPI Bit-bang

J'ai repris les lib. de L'Oled ILLI9431 , sans trop de modifs ..
Toutes les fonctions de base sont OK , y compris les 8 fontes possibles de caracteres
Rajout petit BMP de 120x120 (Daffy Duc)

Projet MikroC 7.60 Pro :
PIC18F27K42_OLED_GC9A01_SPI_Bit_Bang_UART1_MC_2023-03.mcppi
Package : 18F27K42_TEST_SPI_Hw_8Mhz_GC9A01_X_2023-0321.zip
Source : PIC18F27K42_UART1_ADC_SPI_LCD_Rond_CGA9A01_2023-0314.c
Chargeur : PIC18F27K42_UART1_ADC_SPI_Bit_Bang_LCD_CGA9A01_MC_2023-0314.hex
YAT Terminal Log : PIC18F27K42_UART1_ADC_SPI_LCD_Rond_CGA9A01__2023-0313_MC.log

Résultats :
(voir fichier log deroulement de programme )

images/t_OLED_CG9A01_18F27K42_SPI_BB_MC_Test_2023-0312.gif

Nota : le rendu reel de l'ecran OLED est bien mieux que sur la capture avec ma camera webcam Logitech C525.

La vitesse n'est pas tres bonne .. SPI bit bang à 1,47MHz ( comparée au ESP32 et SPI à 10MHz !)
Effacement de l'écran en 1,2sec ( 240x240x2= 57600 x2 = 115200 bytes mis à zero via le SPI ).

CRLF1();
CPrint("sur YAT terminal, show time delta activé !\r\n");
CPrint("Debut du test 1 duree de 100 000 SendCmd encadré de 2 CRLF \r\n");
CRLF1();
for (L1=0;L1<100000;L1++) SendCmd(0);
CRLF1();
CPrint(".fin du test 1\r\n");
CRLF1();

0.000) sur YAT terminal, show time stamp activé !
(0.000) Debut du test 1 duree de 100 000 SendCmd encadré de 2 CRLF
(0.000)
(1.092)
(0.000) .fin du test 1
(0.049)
(0.000)
(0.000) Debut du test 2 Ecran_Noir()

1,092 sec / 100 000 => duree de "SendCmd(0) en 10.92µS
effacement d'ecran en
115200x10,92 /1000 000=> 1,25 sec + quelques µS

Video : Test_GC9A01_18F27K42_MC_SPI_BitBang_20230313.webm

Chargement d'image BMP en zone Flash (MikroC)
(18F27K42)

Du fait de la capacité de 128K Rom Flash du 18F27K42
il est possible, moyennant certaines restrictions pour limiter le code d'application
d'afficher des images BMP stockées en Flash

1er Test
avec Daffy_Duc image de 120x120 .. récupérée coté Web ARDUINO
OK

2em Test
avec image recupéré coté ESP32 ..

"ladybug.bmp" , dimensions 240*240 en True Color = R5G6B5 , 16-bit color depth (64k colors). 173 kB
Image convertie en une table compatible avec le format C , via l'appli
lcd-image-converter
via Options de Conversion :
taille 16bits .
et ordre des octest dans le Mot : mode ‘Little Endian’
couleurs definies en Word (RGB565)
un fichier nomé "ladybug.c" est crée, en ascii , donc editable avec Notepad++
un pixel est codé par un mot de 16 bits
on a 240x240=56700 pixels x2 => 115200 bytes
Cette image , testée OK avec ESP32
voir ESP32WROOM32_240x240_ST7789_ladybug_external.ino

Du fait que MikroC ne peut pas gerer des Block de FLash > 64Ko,
La Table des datas a été scindée en 2 parties.
donc chaque partie est < 64Ko, la somme des 2 = 56700x2=115200 bytes
Avec le programme initial et le code exustant pour gérer les Tests Grafiques : point , ligne ,rectangle ,cercle ..
Il ne reste pas assez de place en flash pour y inserer les 8 fontes de caracteres
et aussi , obligé de limité la 2em partie en rognant les 8 dernieres lignes de pixel
=> partie 1 ....LadyBug1 [] = 0 à 28800 mots => lignes 0 à 119
=> partie 2 ... LadyBug2 [] = 0 à 26880 mots => lignes 220 à 231

3em Test , avec MES images

Probleme : transformer une image en BMP 16bits RGB565 ?
PaintShopPro 5 , ou XNView ne le fait pas, connais <16 bits ou > 16 bits ..mais pas 16 bits
Heuresement il y a cet outil :

dispo ICI
LCD Bitmap Converter for Microchip Library v2.0
BMC4MLA_Setup.exe

Fichier original Airspeed.jpg, crée via Raytracing Moray + Povray (c) PF
Mis à l'echelle 240x240 , puis sauvegardé en BMP classique , via PSP5

Chargement du BMP sur LCD converter
choix du format de convertion : RGB 16 bits 565

Name airspeed_240x240.bmp
Size 172854 byte(s) (240x240px)
Type image/bmp
16bits (2byte/pixel) R5G6B5 RRRRRGGGGGBBBBB
Litle_endian

Convert => Generation d'un fichier compatible Microchip C

les datas sont organisé en lignes de 16 bytes
les couleurs sont representées par 2 bytes et non 1 mot de 16 bits.

1 ligne de data = 8 pixels
il ya 7200 lignes ! soit 7200x8 = 57600 pixels .....( =240x240)

Rappel:
1 ligne de pixel = 240x2=480 bytes
240 lignes = 480*240=> 115200 bytes

Problemos :
ajustements manuels du fichier ...
Diviser le fichier en 2 parties < 64K chacune
Attention : il faut inverser aussi le sens de lecture des datas MSB et LSB ! pour respecter les couleurs !
à croire que le choix (préconisé) Litle_Endian n'est pas le bon !
la premiere partie des datas affiche la partie basse de l'image !
Attention : direction bas-> haut!!
Attention : SetOrientation(2) Portrait\r\n"); ou Paysage (orientation=1) suivant l'image ...
#include "airspeed_565.h"

Au besoin , il faudra eventuellement supprimer quelques lignes d'affichage,
pour recuperer de la place dans la Flash pour la partie programme ..

Modif du programme MikroC pour pouvoir visualiser entierement le * .BMP
Compilation de l'application MikroC conditionnelle avec
#define With_BMP
permettant d'inhiber une grosse partie de code ..et laisser donc de la place pour l'image de 115200 bytes .
#include "airspeed_565.h"

Test Affichage Airspeed ... OK

La meme chose avec un fichier Voltmetre .jpg ( photo prise aux puces de Leyment 01)
Création , apres transformations ....de
#include "voltmetre_565.h "

Test Affichage Voltmetre ..OK

Code de la partie affichage image

CPrint("\r\n Ecran Noir\r\n");
Ecran_Noir();
CPrint(" Affichage Voltmetre.bmp 240x240 65K couleurs\r\n");
SetWindow(0,0,239,239);
CRLF1();
CPrint(" partie 1 \r\n");
i=0;
do
{ SendData(voltmetre_01[i+1]); SendData(voltmetre_01[i]); // organisé en byte et non en word
SendData(voltmetre_01[i+3]); SendData(voltmetre_01[i+2]);
SendData(voltmetre_01[i+5]); SendData(voltmetre_01[i+4]);
SendData(voltmetre_01[i+7]); SendData(voltmetre_01[i+6]);
i=i+8;
} while(i<57600);
CRLF1();
CPrint(" partie 2 \r\n");
i=0;
do
{ SendData(voltmetre_02[i+1]); SendData(voltmetre_02[i]); // organisé en byte et non en word
SendData(voltmetre_02[i+3]); SendData(voltmetre_02[i+2]);
SendData(voltmetre_02[i+5]); SendData(voltmetre_02[i+4]);
SendData(voltmetre_02[i+7]); SendData(voltmetre_02[i+6]);
i=i+8;
} while(i<57600);
CRLF1();

Nota : La qualité reéelle de l'image sur l'OLED est bien meilleure que sur les photos !

La suite ...
à verifier : choix big endian lors de la creation de la table ..?
utilisation de la SD card sur le module Rouge, pour stoker plusieurs BMP ..
et utiliser un tampon RAM de 4Ko, usage du DMA ???

Software
PIC18F27K42_OLED_GC9A01_SPI_Bit_Bang_Image_65Kc_240x232_MC_2023-0315.c

Test SPI Hardware sur BASE 18F27K42
MikroC 7.60

Check signal SPI Hardware sous MikroC
avec Librairie SPI HW MikroE
SPI1_Init_Advanced(_SPI_MASTER_OSC_DIV64 , _SPI_DATA_SAMPLE_MIDDLE, _SPI_CLK_IDLE_LOW, _SPI_HIGH_2_LOW );
la lib propose
_SPI_MASTER_OSC_DIV16 => SPI à 4MHz
_SPI_MASTER_OSC_DIV64 => SPI à 1MHz

Sinon on peut diminuer la vitesse via
// modif vitesse SPI (car mikroC n'a pas cette option en librairie)
SPI1SPIEN_bit=0;
SPI1CLK = 0x02; // choix MFOSC=500KHz
SPI1BAUD = 0x01; //
FBAUDS= F(CLKSEL)/((SPI1BAUD+1)= 500kz MHz / 2*(1+1)=> SPI Speed =125KHz
SPI1SPIEN_bit=1;
nota : Timer2 peut AUSSI servir de base de temps.

Remarque : Le signal SPI Hardware est carré ! contrairement au SPI bit bang ...
L'init de L'oled ne se fait plus correctement ????

images/t_Test_init_CG9A01_SPI_Hardw_MC_2023-0307.gif

Pas de suite ...je n'insiste pas de coté là, vu que je vais passer sur XC8 ,
pour la version SPI Hardware avec 18F27K42

OLED GC9A01 avec 18F27K42 , XC8 MPLAB et SPI

Transposition de la version MikroC en bit bang (qui est OK) vers MPLAB XC8
Application permettant de tester les 2 cas : SPI bit bang ou SPI Harware

Hardware commun aux 2 versions :
voir Defines_datas.h

résumé:
PORT B pour les commandes _RST,_CS, _DC (ou A0)
PORT C pour le SPI HW. SCLOCK et MOSI
PORT A pour SQA trigger et led rouge
PORTC RC6=TX RC7=RX ...UART1

en version Bit-bang SPI software

en validant cette directive :
#define With_SPI_Software

Test Trame et Test Init OLED avec SQA analyser :

l'init de l'OLED est OK

En version SPI Hardware
en validant cette directive :
#define With_SPI_Harwdare

images/t_SPI_Hardware_18F27K42_Diagram.gif

Test (bizarre) avec SQA Analyser sur une trame de 9 valeurs

Test TRAME :

images/t_SQA_18F27K42_TEST_Trame_SPI_HW_8MHz_2023-0319_X.gif

CPrint(" SPI HARDW Sequence : 0x01 0x10 0X20 0x40 0x80 0xAA 0x0F 0x55 0xF0 \r\n")
Apparement, il y a une anomalie du decoder SPI de l'analyser !

MAIS NON ! PROBLEME DE CONFIG. HARDWARE MCU
=> Modif :
SLRCONC =0x80; was 0xFF ,pour débrider la vitesse de réponse des sorties SPI !
Re test de la TRAME :

le resultat est Maintenant OK !

Analyse trame d'init OLED ...

images/t_SQA_18F27K42_SPI_Hardw_8MHz_Init_GC9A01_20230319.gif

SPI Hardware 8MHz

Problemes rencontrés sur l'usage de SMT1 compteur 24bits
pour chronometrer la durée de certaines fonctions..
Oubli de traiter le debordement du compteur 24 bits ..
nota : cas déja vu et traité (via interruption) dans l'appli Frequencemetre SMT1 !
c'est vite fait avec FOSC=64MHz !
Rajout alarme débordement du compteur SMT1 via l'état du flag PIR1bits.SMT1IF
et si armé, rajout de la valeur 0x1000000 correspondant à 0xFFF FFFF +1
+ message "Over !"
Pour avoir une plus grande dynamique de mesure , tout en restant à +-0,25µS de reolution
passé le CLOCK SMT1 de 64MHz à FOSC/4 soit 16MHz
..tout en restant à +-0,25µS de resolution !

voir fichier source pour les details de ;
void Stop_SMT1()
{.....etc...
if (PIR1bits.SMT1IF==1)
{
CPrint("\r\n Over !\r\n");
SMT1_Measure=SMT1_Measure+0x1000000;
}
PIR1bits.SMT1IF=0 ;
..etc..... }

void Start_SMT1()
void SMT1_Init()
{
......etc.......
// REGISTER 25-4: SMT1CLK: SMT CLOCK SELECTION REGISTER 16MHz
// 000=FOSC/4 001=FOSC 010=HINTOSC 16MHz 100=MFINTOSC 500Khz
// 500KZ => resolution +-2µS; 64MHZ=> resolution +- 62,5nS
// FOSC/4 =16MHZ
SMT1CLKbits.CSEL2= 0;
SMT1CLKbits.CSEL1= 0;
SMT1CLKbits.CSEL0= 0;
.....etc.........
}

Test SMT1 avec :
CPrint(" Mesure SMT1 pour __delay_ms(2000);\r\n");
Start_SMT1();
__delay_ms(2000);
Stop_SMT1();

resultats:
09:33:53.850) Mesure SMT1 pour __delay_ms(2000);
(09:33:55.843) Over !
(09:33:55.864) Stop. SMT1=32000006 ,soit 2000000 uS
(09:33:55.864)

(09:33:58.883) Start SMT1 pour Init_CG9A01();
(09:33:59.647) Stop. SMT1=12401421 ,soit 775088 uS ....... 775mS

09:33:59.947) Test duree Ecran Noir (SPI 8MHz!)
(09:34:00.247) Stop. SMT1=4666010 ,soit 291625 uS .........292mS

(09:34:10.592) Test Duree de Chargement image Voltmetre.bmp
(09:34:10.996) Stop. SMT1=6321619 ,soit 395101 uS........395mS

voir fichier log , déroulement du programme
YAT-Log-20230321-093345.log

voir Discussions sur le forum Fantaspic en C ou en ASM

Rajout Forçage entrée SS SPI ,via LATC2
L'Init OLED se fait OK !
Test à 2MHz , puis à 8 MHz
Verif à l'oscilloscope periode signal SCLK RC3 => 126 nS mesuré ( nota : OSCTUNE=0)

Nota :

Memory Summary:
Program space used 1F2D1h (127697) of 20000h bytes ( 97.4%)
Data space used 268h ( 616) of 2000h bytes ( 7.5%)
Configuration bits used 5h ( 5) of 5h words (100.0%)
EEPROM space used 0h ( 0) of 400h bytes ( 0.0%)
ID Location space used 10h ( 16) of 10h bytes (100.0%)

Du fait de l'usage de la ROM FLASH pour y loger une image BMP de 115200 bytes !
je ne peux pas, dans cette version, integrer toutes les autres fonctions liées à l'ecran OLED
telles que l'ecriture de characteres , avec 8 fontes differentes ..etc ...;
donc autre version à venir ..avec BMP sur SDCard !

SOFTWARE :
mon dossier : C:\MPLABX_Projects\18F27K42_TEST_SPI_2023.X

Le fichier de Configuartion MCU Config_bits.h
FOSC interne =64Mhz
Fichier d'init du OLED GCA901 : Init_GC9A01.h
Les Couleurs prédéfinies : RGB_565_colors.h
Image Voltmetre .bmp .. 2 tables de 57600 bytes : voltmetre_565.h
Image LadyBug.bmp .. 2 Tables de 28800 mots : LadyBug_.h
les 8 fontes de caracteres : TFT_Fonts_320x240_ILI9341_2023.h

le fichier principal main.c (renomé ) main_X_SPI_HW_20230321.c
pack : 18F27K42_TEST_SPI_Hw_8Mhz_GC9A01_X_2023-0321.zip
executable avec image voltmetre : 18F27K42_TEST_SPI_HW_GC9A01_X_2023-0321.hex

TEST SPI clock à 16 MHz

parametre dans : My_Init_SPI1()

SPI1CLK = 0; // CLKREF =0 ->FOSC=64 MHz
SPI1BAUD = 0; // SPI Speed 64MHz / (2x(1+1)) = 64/4 = 16 MHz
ne pas oublier : inhibition du Slow Rate
SLRCONC=0;
SLRCONB=0;

SPI à 16MHz .... gain en durée tres minime !
verif à l'oscillo SCLK -> 62.5nS 16MHz !

(08:31:17.025) Init OLED Rond CG9A01
(08:31:17.057) Start SMT1 pour Init_CG9A01();
(08:31:17.806) Stop. SMT1=12401186 ,soit 775074 uS....... 775mS ( 775mS à 8MHz !!)
voir explication sur Fantaspic coté ASM
Gaps temporels sur signal SCLK et surtout entre chaque envoi de byte ...

(08:31:18.060) Test duree Ecran Noir (SPI 16 MHz!)
(08:31:18.316) Stop. SMT1=3974743 ,soit 248421 uS......... 248mS ( 291mS à 8MHz)

(08:31:26.720) Test Duree de Chargement image Voltmetre.bmp
(08:31:27.064) Stop. SMT1=5630418 ,soit 351901 uS......... 351mS ( 395ms à 8MHz)

TEST SPI clock à 32 MHz

parametre dans : My_Init_SPI1()

SPI1CLK = 0; // CLKREF =0 ->FOSC=64 MHz
SPI1BAUD = 0; // SPI Speed 64MHz / (2x(0+1)) = 64/2 = 32 MHz

init SPI clock à 32 MHZ
verif à l'oscillo ..periode 31,2nS ....32,05MHz
le clock parait plutot sinusoidal ... mais mon oscillo n'à que 1GS/sec et 70MHz de bande passante

surprise ... L'OLED arrive à suivre ..!

malgré un montage sur breadboard et filerie de 8cm entre MCU et OLED
(on ne parle pas ici de probleme CEM!)

(09:12:00.852) Test duree Ecran Noir (SPI 32 MHz!)
(09:12:01.064) Stop. SMT1=3283477 ,soit 205217 uS ..... 205mS ....( 292mS at 8MHz)

(09:12:09.247) Test Duree de Chargement image Voltmetre.bmp
(09:12:09.548) Stop. SMT1=4939218 ,soit 308701 uS .... 308mS..... ( 395ms at 8MHz)
(09:12:09.558) ..fin Affichage Image voltmetre

Ultime test avec le minima de code :

void SendData(Byte c) // SS low par LATC2=0 ayant été fait au préalable
{
_DC = 1;
SPI1TXB = c;
c = SPI1RXB;
}

void SendCmd(Byte c) // SS low par LATC2=0 ayant été fait au préalable
{
_DC = 0;
SPI1TXB = c;
c = SPI1RXB;
}

c = SPI1RXB; //reste indispensable ..

L'OLED arrive toujours à suivre ..sans probleme détécté !

(11:23:20.907) Test duree Ecran Noir (SPI 32 MHz!)
(11:23:21.046) Stop. SMT1=2131367 ,soit 133210 uS ........133mS
(11:23:21.056)

(13:22:46.662) Test Duree de Chargement image Voltmetre.bmp
(13:22:46.888) Stop. SMT1=3672018 ,soit 229501 uS .... 229mS
(13:22:46.901) ..fin Affichage Image voltmetre

Diminution de la durée Ecran Noir
en divisant le nombre d'iteration par 10

void Ecran_Noir(void)
{ Word i;
SendCmd(0x2A);
SendData(0);SendData(0); SendData(0);SendData(0xEF);
SendCmd(0x2B);
SendData(0);SendData(0); SendData(0);SendData(0xEF);
SendCmd(0x2C);
for (i=0;i<5760;i++)
{ SendData(0x00);SendData(0x00);
SendData(0x00);SendData(0x00);
SendData(0x00);SendData(0x00);
SendData(0x00);SendData(0x00);
SendData(0x00);SendData(0x00);
SendData(0x00);SendData(0x00);
SendData(0x00);SendData(0x00);
SendData(0x00);SendData(0x00);
SendData(0x00);SendData(0x00);
SendData(0x00);SendData(0x00);

}

(13:22:38.885) Test duree Ecran Noir (SPI 32 MHz!)
(13:22:38.991) Stop. SMT1=1561116 ,soit 97569 uS ...... 98mS au lieu de 133ms

Optimisation chargement image ,
via l'usage de pointeurs .
et un peu plus de code utilisé ...

23/03/2023
(14:22:04.791) Test Duree de Chargement image Voltmetre.bmp
(14:22:04.981) Stop. SMT1=3074432 ,soit 192152 uS ..............192mS ! ....(au lieu de 229mS)

Start_SMT1();
i=0;
SQA=1;
p1=&voltmetre_01[0];
for (i=0;i<57600;i=i+16)
{
SendData(*(p1+1)); SendData(*(p1));
SendData(*(p1+3)); SendData(*(p1+2));
SendData(*(p1+5)); SendData(*(p1+4));
SendData(*(p1+7)); SendData(*(p1+6));
SendData(*(p1+9)); SendData(*(p1+8));
SendData(*(p1+11)); SendData(*(p1+10));
SendData(*(p1+13)); SendData(*(p1+12));
SendData(*(p1+15)); SendData(*(p1+14));
p1=p1+16;
}
p2=&voltmetre_02[0];
for (i=0;i<57600;i=i+16)
{
SendData(*(p2+1)); SendData(*(p2));
SendData(*(p2+3)); SendData(*(p2+2));
SendData(*(p2+5)); SendData(*(p2+4));
SendData(*(p2+7)); SendData(*(p2+6));
SendData(*(p2+9)); SendData(*(p2+8));
SendData(*(p2+11)); SendData(*(p2+10));
SendData(*(p2+13)); SendData(*(p2+12));
SendData(*(p2+15)); SendData(*(p2+14));
p2=p2+16;
}
SQA=0;
Stop_SMT1();

M.A.J. SOFTWARE :

Init_GC9A01.c
RGB_565_colors.h
18F27K42_TEST_SPI_HW_GC9A01_X_2023-0321.hex
18F27K42_TEST_SPI_Hw_32Mhz_GC9A01_X_2023-0322.zip
18F27K42_TEST_SPI_HW_32MHz_GC9A01_X_2023-0322.hex
main_X_SPI_HW_32Mhz_20230322.c

Version 2024 , Texte + graphique
OLED GC9A01 , SPI Hardware 18F27K42

Les differentes Fontes sont predefinies en FLASH ROM
Pour les utiliser en RAM, usage des fonctions malloc et free, pour obtenir un espace RAM (de travail) correspondant à la taille de la Fonte
Cet espace est ensuite libéré apres usage , de sorte à n'utiliser qu'UNSEUL ESPACE RAM commum à toutes les fontes.
Malheureusement , il ne rest que peu d'espace ROM , impossibilité d'afficher un BMP de 240x240 16bits couleurs..
Neamoins il reste encore suffisament de la place pour aficher un BMP de 128x128 !

Le HEADER de chaque fonte contient les informations suivantes
// rectif Header 13/11/2023
// cfont.width=6 // largeur de la fonte en pixels
// cfont.height=8 // hauteur de la fonte en pixels
// cfont.offset = 0x20=SPACE // origine de la fonte (caracteres imprimables ONLY)
// cfont.numchars= 96 // nb de chars definis dans la fonte
// cfont.MaxC // =Nb de chars maxi par ligne / cfont.width)
// cfont.Taille xxxx

Liste des Fontes :

// (#1) Taille Font TerminaL6x8 = 672+7=679 cfont.MaxC= 34
// (#2) Taille TerminaL12x16 = 2400 cfont.MaxC= 14
// (#3 Taille Font Trebuchet_MS16x23 = 1279 cfont.MaxC= 14
// (#4) Taille Font Arial_Narrow22x32 = 2319 cfont.MaxC= 8
// (#5) taille Font NI7SEG22x28 = 2319 cfot.MaxC = 8
// (#6] Taille Font NI7SEG26x35 = 1708 cfont.MaxC= 6
//---- Taille Font Trebuchet_MS13x21 = 1045 cfont.MaxC= 18 car dont 0
// --- Taille Font Terminal5x11 = 1056 cfont.MaxC= 48
Suivant la taille des caracteres, on ne peut pas stocker la totalité des caracteres de la table ascii ..(96 caracteres imprimables)
Ou alors, c'est inutile ....par exemple avec des caracteres 7 segments !

images/t_Fontes_OLED_CG9A01__2023-1115.gif

modif. branchement Hardware du CG9A01 ..pour liberer RB0 .
RB1=CS , RB2=RST , RB3=DC/A0 SPI MOSI=RC5 SPI Clock=RC3
voir Defines_datas_2024-0211.h

M.A.J. SOFTWARE : 11/02/2024

Pack projet : 18F27k42_OLED_SPI_Hw_CG9A01_2024-02.zip
Chargeur : _18F27k42_OLED_SPI_Hw_CG9A01_2024-0211.X.hex
main : main_Oled_CG9A01_2024-0211.X.c
Bmp 128x128 : Daffy_Duck_Bmp.h

et *.BMP sur SDCARD
à suivre

OLED GC9A01 sur module ESP32 Vroom DevkitV1

Pas trop de mérite, application d'une recette de cuisine ARDUINO ! ....
via ce lien TRES bien documenté : https://dronebotworkshop.com/gc9a01/#GC9A01_with_ESP32
Mais cela permet de valider le fait que votre ecran OLED soit OK !

HARDWARE :

GC9A01A Test avec ESP32 Vroom32 Devkitv1 30 pins, repère Rouge!
Version :08-03-2023

Liaison SPI Hardware :
ESP32 Pin 18 SCLK
ESP32 Pin 23 MOSI
Controle
#define TFT_DC .....15 // ESP32
#define TFT_CS ......4 // ESP32
#define TFT_RST... 19 // ESP32
la pin LED du module OLED est relée à +VCC via R de 1K à 10K
...sinon Ecran NOIR!
L'OLED est alimenté via le 3,3V du module ESP32
lui meme alimenté via la liaison USB au PC

images/t_Oled_GC9A01_SPI_ESP32_connections_test_2023-0308.gif

usage de l'IDE Arduino 1.8.16 pour la compilation et chargement.

SOFWARE:
Utilise librairie Adafruit_GC9A01A.h
Init SPI :
Adafruit_GC9A01A tft(TFT_CS, TFT_DC,TFT_RST);

ESP32_Oled_GC9A01_SPI_test_2023-03.zip
ESP32_Oled_GC9A01_SPI_test_2023.ino

YAT Terminal log:

Init TFT OLED CG9A01 .. Start SQA analyser dans 4 sec
Benchmark Time (microseconds)
Screen fill 150342
Text 27991
Lines 196498
Horiz/Vert Lines 13718
Rectangles (outline) 11864
Rectangles (filled) 415811
Circles (filled) 57499
Circles (outline) 89004
Triangles (outline) 58975
Triangles (filled) 156466
Rounded rects (outline) 43102
Rounded rects (filled) 422293
Done!

Application TRES RAPIDE !
Remplissage écran en 150mS ............contre 192mS avec PIC18F27K42 SPI HW 32Mhz..